One of the most compelling uses of virtualization technology is its ability to consolidate applications originally running in multiple machines into a single physical server by executing each of them in a separate virtual machine. For virtual machines running on the same physical machine, significant redundancy among them is likely to exist. Memory de-duplication, which is supported in various virtualization systems, aims to eliminate memory resource waste due to such redundancy. However, because of mismatch in page alignment and use of physical pointers, not all memory-level redundancy can be effectively and efficiently uncovered.
Another way to eliminate this redundancy is through kernel component refactoring, which takes out common kernel components shared by virtual machines running on the same physical machine and runs them on a separate virtual machine called a virtual appliance. A virtual appliance execution architecture may provide several advantages. First, the overall resource usage may be reduced because the inter-virtual machine redundancy is minimized. Second, the development effort for common kernel components may also be reduced because they now may be developed in a way that is largely independent of the platforms of the user virtual machines. Finally, for security-related kernel components, moving common kernel components into a separate virtual machine may render the common components immune from kernel compromises in user virtual machines.
Many applications running on a virtual appliance may need to interact with the user virtual machines when certain events occur. For example, when an anti-virus scanning virtual appliance application detects an anti-virus string signature in a user virtual machine's physical memory block, the virtual appliance may need to first identify to which process the memory block belongs, and then terminate the process if necessary. To find out which process owns which physical memory blocks and then terminate these processes may involve invoking systems service functions specific to the user virtual machine in question, and thus cannot be directly initiated by the virtual appliance virtual machine, which is outside the user virtual machine. One way to address this problem is to install in each of the user virtual machines an in-guest agent that acts as a proxy which retrieves information from, and exercises control over, the user virtual machine in which it is located.
Unfortunately, conventional virtual-appliance agent insertion and invocation may be inefficient and/or ineffective. For example, installing an agent in a user virtual machine may involve substantial effort for data center administrators. Furthermore, putting the agent of a security-related virtual appliance application into a user virtual machine may introduce the risk that a kernel rootkit (or other malware) in the user virtual machine may disable or tamper with the agent and thus indirectly cripple the associated virtual appliance application.